Christoph Berg: Machine Check Exception
Today's wtf:
Wed Jul 18 20:25:01 CEST 2012 MCA: Generic CACHE Generic Generic Error
Today's wtf:
Today's wtf:
Today's wtf:
Wed Jul 18 20:25:01 CEST 2012 MCA: Generic CACHE Generic Generic Error
May 7th, 2012
Photo by Wouter Verhelst
Check out his interview to learn more about some of the numerous ways one can get involved in Debian, managing its infrastructure and without having to be a packager.
Raphael: Who are you?
J rg: My name is J rg Jaspert and I m 35 years old working for a small company
doing system administration and consulting work for our customers.
I m married for a little while now and sometime soon a little Ganneff
will be crawling out of my wife. (Whoever didn t think of the movie
Alien now is just boring).
Raphael: How did you start contributing to Debian?
J rg: I started using Debian somewhere around 2000, 2001. Before that I had
the misfortune to try SuSE and RedHat, both with a user experience that
let me fully understand why people think Linux is unusable. (Due to my
work I m in the unfortunate situation to have to use RedHat on two
machines. Funny how they are still utter crap and worse than bad toys).
And all of this lets get a Linux running here came up because I was
trying to find a replacement for my beloved OS/2 installation, which I
had for some years.
So after I got Debian installed, good old Potato, I got myself active on
our mailing lists, starting with the German user one.
A bit later I replied to a question if someone can help as staff for a
Debian booth somewhere. It was the most boring event I ever visited
(very nice orga, unfortunately no visitors), but I got a few important
things there:
How that turns out with the baby I have no idea yet. I do want to train
it to like pressing the M key, so little-Ganneff can deal with NEW all
on its own (M being Manual reject), but it might take a day or twenty
before it gets so far.
Raphael: Thanks to the continuous work of many new volunteers, the
NEW queue
is no longer a bottleneck. What are the next challenges for the FTPmaster
team?
J rg: Bad link, try this one.
Also, no longer sounds like its recent. It s not, it s just that
people usually recognize the negative only and not the positive parts.
Well, there are a few challenges actually. The first one, even if it
sounds simple, is an ongoing one: We need Debian Developers willing to
do the work that is hidden behind those simple graphs.
Yes, we are currently having a great FTP Team doing a splendid work in
keeping that queue reasonably small this is a/THE sisyphean task per
excellence. There will always be something waiting for NEW, even if you
just cleaned the queue, you turn around and there is something else back
in already. Spreading this workload to more people helps not burning one
out.
So if one or more of the readers is interested, we always like new
volunteers. You simply need to be an uploading DD and have a bit of free
time. For the rest we do have training procedures in place.
Another one is getting the multi-archive stuff done. The goal is to
end up with ONE host for all our archives. One dak installation. But
separate overrides, trees, mirrors, policies and people (think RMs,
backports team, security team). While this is halfway easy to think of
in terms of merging backports into main it gets an interesting side
note when you think of merging security into main . The security
archive does have information that is limited to few people before
public release of a security announce, and so we must make sure our
database isn t leaking information. Or our filesystem layer handling. Or
logs. Etc. Especially as the database is synced in (near) realtime to a
DD accessible machine. And the filesystem data too, just a little less
often.
There is also a discussion about a good way to setup a PPA for Debian
service. We do have a very far developed proposal here how it should
work, and I really should do the finishing touches and get it to the
public. Might even get a GSoC project on it.
So far for some short to middle term goals. If you want to go really
long term, I do think that we should get to the point where we get rid
of the classical view of a source package being one (or more) tarballs
plus the Debian changes. Where a new version requires the full upload of
one or more of those parts of the source package.
I don t know exactly where it should end up. Sure, stuff like one
central DVCS, maintainers push there, the archive generates the source
tarballs and prepares the mirrors do sound good for a quick glance. But
there are lots of trouble and pitfalls and probably some dragons hidden
here.
Raphael: The Debian repositories are managed by DAK (Debian Archive Kit)
which is not packaged. Thus Debian users pick tools like reprepro to manage
their package repositories. Is that how things should be?
J rg: Oh, Mark Hymers wants to do a package again. More power to him if he does,
though yes, DAK is not exactly a quick-and-easy thing to install.
But nowadays it is a trillion times easier than the past thanks to
Mark s work people can now follow the instructions, scripts and
whatever they find inside the setup directory.
Still, it really depends on the archive size you are managing. A complex
tool like dak does not make sense for someone who wants to publish one
or a dozen of his own packages somewhere. Thats just like doing a finger
amputation with a chainsaw it certainly works and is fun for the one
with the chainsaw but you probably end up a little overdoing it.
I myself am using dpkg-scan[packages sources] from a shell script but
also mini-dinstall in places (never got friend with reprepro when I
looked at it). Works, and for the few dozen packages those places manage
it is more than enough.
Also, using dak forces you into some ways of behaviour that are just
what Debian wants but might not be what a user wants. Like inability
to overwrite an existing file. One of the reasons why mentors.debian.net
won t work with dak. Or the use of a postgres database. Or that of gpg.
Sure, if you end up having more than just a dozen packages, if you have
many suites and also movement between them, then dak is sure a thing to
look at.
And how should things be : however the user and admins of that certain
install of reprepro, mini-dinstall, dak, whatever want it. This is not
one-tool-for-all land
Raphael: What is the role of Debian Account Managers (DAM)? Do you believe
that DAMs have a responsibility to shape Debian by defining limits
in terms of who can join and what can be done within Debian?
J rg: Quote from https://lists.debian.org/debian-devel-announce/2010/10/msg00010.html:
The Debian Account Managers (DAM) are responsible for maintaining the list of members of the Debian Project, also known as Debian Developers. DAMs are authoritative in deciding who is a member of the Debian Project and can take subsequent actions such as approving and expelling Project members.Now, aside from this quote, my OWN PERSONAL OPINION, without wearing anything even vaguely resembling a DAM hat: DAM is the one post that is entitled to decide who is a member or not. Usually that is in the way of joining (or not), which is simple enough. But every now and then this also means acting on a request to do something about whatever behaviour of a Debian Project member. I hate that (and i think one can easily replace I with WE there). But it s our job. We usually aren t quick about it. And we don t act on our own initiative when we do, we always have (numerous) other DDs complain/appeal/talk/whatever to us first. The expulsion procedure , luckily not invoked that often, does guarantee a slow process and lots of input from others. Are we the best for it? Probably not, we are just some people out of a thousand who happen to have a very similar hobby Debian. We aren t trained in dealing with the situations that can come up. But we are THE role inside Debian that is empowered to make such decisions, so naturally it ends up with us. Raphael: You did a lot of things for Debian over the years. What did bring you the most joy? Are there things that you re still bitter about? J rg: The most joy? Hrm, without being involved in Debian and SPI I would never have met my wife.
Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.
One comment Liked this article? Click here. My blog is Flattr-enabled.
Ever wondered how much memory a program needed? Install the "time" package:
$ /usr/bin/time ls [...] 0.00user 0.00system 0:00.00elapsed 0%CPU (0avgtext+0avgdata 4000maxresident)k 0inputs+0outputs (0major+311minor)pagefaults 0swapsUnfortunately the "time" bash built-in makes it necessary to use the full path. Thanks to youam for the tip. Update: aba notes that calling \time works as well. Thanks!
When packaging new backport versions, I diff the old Debian package with the
old backport package to extract the changes I did there, and then apply this
patch to the new version. There is always a reject in debian/changelog because
the topmost bpo entry won't apply cleanly to the new changelog. To fix this, I
invoke "vi debian/changelog*" and manually copy the rejected hunk.
Unfortunately, I regularly end up copying it from debian/changelog.rej
(buffer 3) into debian/changelog.orig (buffer 2) instead of debian/changelog
(buffer 1). Here's the fix in my .vimrc:
" Prevent accidental editing of patch .orig files autocmd BufRead *.orig set readonly
PostgreSQL's libpq5 package got its symbols file somewhere around version 8.4,
so the symbols in there were all marked with version "8.4~" or greater. As I'm
working on pgapt.debian.net aiming at
providing packages for all upstream-supported PG versions (currently 8.3 and
up), this made packages incompatible with 8.3's libpq5.
There didn't seem to be a ready program to feed a series of .deb files which
would then run dpkg-gensymbols and build a symbols file, so I wrote this shell
script:
#!/bin/sh
set -eu
[ -d tmp ] mkdir tmp
i=1
for pkg in "$@" ; do
echo "$pkg"
test -e "$pkg"
name=$(dpkg-deb -I "$pkg" perl -lne 'print $1 if /^ Package: (.+)/')
version=$(dpkg-deb -I "$pkg" perl -lne 'print $1 if /^ Version: (.+)/')
out=$(printf "tmp/%03d_%s" $i "$version")
dpkg-deb -x "$pkg" "$out"
dpkg-gensymbols -P"$out" -p"$name" -v"$version" \
$ oldsymbols:+-I"$oldsymbols" -O"$out.symbols" \
tee "$out.symbols.diff"
test -s "$out.symbols.diff" rm "$out.symbols.diff"
oldsymbols="$out.symbols"
rm -rf "$out"
i=$(expr $i + 1)
done
To use it, do the following:
It's about time that Rapha l is interviewed in the "People behind
Debian" series he initiated on his
blog.
Indeed, when he interviews people, Rapha l asks about other people
they could suggest for next interviews. So, during mine, I suggested
him to be a next "victim". As he couldn't interview himself, I
volunteered for this.
As you'll see below, Rapha l (who's a friend of mine as I'm a friend
of his) likes to speak and that shows in the length of his answers
:-) but you always know more about Debian when reading his blog posts,
books, mails, etc. I personnally think that he is among the best
promoters of the project for years and it was a pleasure for me to
conduct this interview.
My questions are in bold, the rest is by Rapha l.
Who are you?
Hi, Rapha l Hertzog, I'm a 32 years old French Debian developer who is
married and who has a 2-year old son. I'm running my own company (Freexian) since 2005, I started
it 3 years after the end of my computer science studies. I'm also a very
proud author of the Cahier de
l'Admin Debian, a French book about Debian.
You often wrote about your attempts to make your living partly, if
not completely, out of your Debian work. Can you describe the way
you're trying to do this?
My first try has been with Freexian. I always advertised this company
as being specialized in Debian GNU/Linux. While Freexian is successful
enough to provide me a decent income, I'm not really satisfied with the
result because very few of my contracts are about improving Debian. I
use Debian daily for the benefit of my customers, writing new customer
specific (embedded) software, deploying a service on Debian servers, etc.
But except for the occasional bugfix, all this work does not improve
Debian (the only exception has been the dpkg multiarch implementation
work sponsored by Linaro).
The positive side is that I don't need to fill my entire schedule to earn
enough money to live. So I'm regularly taking some days off work to be
able to contribute to Debian. This is a freedom that I enjoy...
My French book has also been a bestseller and depending on the years
the royalties represented between 1 and 2 months of supplementary time
that I can spend on Debian (that is between 2000 and 4000 EUR of income).
Now since last year, I decided to actively work towards my goal of making
a living out of my Debian work. I want to build on what has been most
successful for me up to now, that is my book. My strategy has been to
build an audience around my blog: with a direct contact with my readers I
have the opportunity to sell e-books, and without any intermediary taking
the biggest part of the price, I don't need a very large audience to be
successful.
I have also been experiencing micro-donations with Flattr, people who are
enjoying my articles on my blog can use it to give a few cents for each
article they find useful. With a large enough userbase, this could fund
free documentation and would avoid the need for commercial e-books but
we're not there currently and I don't know if it will ever reach the
critical mass.
Last but not least, I'm soliciting donations for my Debian work on the
sidebar of my blog, and I have the chance to a have a few (regular) donators.
You're a proud father since last year. How do you manage your
commitment to the project with your family life?
There are few things that I put above Debian in my life, but my family
certainly is. I try to handle most of my Debian duties during work
hours so that I can spend time with my family on evenings and during
week-ends but in truth I never really disconnect from Debian. It happens
quite often that I say to my wife I'll come in a few minutes, let me
finish this and then I end up responding to a Debian mail, or an IRC
query and take 30 minutes instead of the 5 expected ones. I try hard to
avoid this but it's difficult. Luckily for me, my wife is very supportive
of my Debian involvement and knows me well...
By the way my wife is using Debian on her computer, and my son has already played
with DoudouLinux (a Debian derivative!).
Have you already been accused of self-promotion in your writings? If
that would ever happen, what would you answer to that?
Yes, more than once. I am proud of what I do for Debian, I enjoy sharing
the result of my work. Because of this, some people believe that I'm
selfish and egocentric. And this has somewhat increased since I have been
soliciting donations: for me it's important to be transparent towards
donators so that they see what I really do for Debian. But some people
have the feeling that I'm getting undeserved attention and that I bring
everything towards my own person. On the other side, as an author, I'm a
public figure who is definitely seeking some attention...
I don't have any miraculous answer, we are a large and diverse community,
it's next to impossible to please everybody. I listen to all the concerns
that people bring forward, I take them into account as much as possible,
in particular when I believe they are reasonable/well justified, or when
they come from people that I highly respect. But sometimes I have to plainly
ignore them too... in particular when they are trying to impose their
own political view on a topic that's not directly related to the only
value that we all share: the social contract.
Contributing to Debian is a challenge, we all have to make efforts to
put aside our differences and to concentrate on the work that brings
us closer to the best free software operating system ever built.
You recently launched a campaign to free out the soon-to-be-published
"Debian Administrator Handbook", an English version of your
well-known book about Debian in French. Can you tell us more about
this project?
My French book has been very successful at helping people to get started
with Debian, and like I already explained, it was also effective to fund a
part of my Debian work. So I wanted to make it available world-wide by
publishing an English translation of it. I tried to find an
English-speaking editor willing to take on the challenge but I found none
interested.
Not put off by a setback, Roland (my co-author) and I decided to negotiate
with our French editor Eyrolles to recuperate the necessary rights to
translate the book into English. Handling everything ourselves represents
a lot of work, but it also means that we have the freedom required to decide
of the license of the resulting book. We would love to see it under
a license compatible with the Debian Free Software Guidelines.
But at the same time we firmly believe that we deserve a reasonable
monetary compensation for the work on the book, so we conditioned its
liberation to a predefined amount of money (25 K ) in what we call the
"liberation fund". And since we wanted to be sure that we would have the
required means to complete the translation, we used a crowfunding platform
to seek support of people interested by the book. With such a platform
you're only debited if the minimal requested amount is reached. Anyone
can participate, pre-order the book and/or put some money in the
liberation fund.
As of today, we already reached the minimal funding goal (15 K ) so the
book translation will happen. But the liberation target has not yet been
reached so we don't know yet if the book will be free from the start...
you can follow the progress right on the fundraising page or
on the website dedicated to the
book.
PS: If you want to contribute to this project and also make a donation
to Debian at the same time, you should check out this page.
You're one of the main developers of dpkg, a critical tool for
Debian systems. Can you tell us more about the current development
challenges it is facing? What will be the new dpkg features for
wheezy?
The current challenges are not really technical. dpkg is a relatively
mature piece of software and it will continue to work for the foreseeable
future without needing much maintenance work.
The real challenge is trying to setup a healthy developement community
around it so that we can keep tackling new interesting problems (there are
many listed in the roadmap and in
the 225 wishlist bugs).
There is a real problem of leadership and communication in the current
team. We used to be three, and we're only two nowadays. Guillem is the
legitimate leader since he's involved in dpkg's developement since early
2006 while I joined only in late 2007. But in the last 4 years, we did not manage to recruit anyone
else on the team. Some persons tried to contribute significant new
features (like Sean Finney with a rework of the way we handle
configuration files) but they gave up frustrated after a while because we
did not manage to review their work (and discuss the design) in any
reasonable timeframe. Another famous case is Ian Jackson with his trigger
work. His work got merged, but so late that in the mean time he blew up
while trying to hijack
the maintenance of dpkg.
For a long time I was concentrating my work on the Perl part of dpkg (aka
dpkg-dev mainly), so I did not feel qualified to review and merge work
related to the C part and I was just a worried observator of this
situation. I tried to improve it by setting up some basic
review
infrastructure, it should have brought some lisibility to the status
of each change left to be reviewed... but it has not been used
and it changed nothing.
Over the years, I became much more interested in the C part. My first big
contribution in C has been the rewrite of update-alternatives (from Perl
to C). I made other small changes in between, but at the start of this
year I had this great opportunity to work on the multiarch implementation
(FYI, multiarch is the
possibility to mix packages from several architectures on a single
system). This really forced me to jump into the C codebase and learn a lot about
how dpkg is implemented. Thanks to this I have been able to tackle other
small projects (like the improved triggers).
This would be all great if my multiarch work was already merged, but
it's not. It's a large work, I do not mind waiting a bit in particular
since Guillem is a highly skilled C programmer. His sharp analysis of new
designs are invaluable, when he reviews code he always finds something to
improve. I learnt a lot just by reviewing the code he wrote over the
years.
That said I have been waiting since April without almost no updates from
him. With the release team asking us
to hurry up, the situation is getting somewhat strained as I really
want to see multiarch in Wheezy and I do not really want to short-circuit
Guillem.
Hum, I may have drifted a bit from your original question... what great
new features can people expect? Well multiarch is supposed to be the big
new feature, apart from that there aren't many things that matter to the
end users. But there are already quite a few changes
that are of interest to package maintainers (like hardened build
flags, source package improvements, improved triggers, ).
What's the biggest problem of Debian?
Manicheism and a tendency to quickly polarize the discussions. In reality,
there are very few situations where everything is all good or all bad.
Ever since I have read The 7
Habits of Highly Effective People I try hard to put into practice the
habits of interdependence . Instead of having only my point of view in
mind, I try to understand the motivations from the other party ( Seek
First to Understand, Then to be Understood ) in order to be able to put
forward solutions acceptable to both parties ( Think Win-Win ).
I highly recommend this book to anyone. And I invite everybody to
at least try to follow those simple advices.
Is there someone in Debian you admire for their contributions?
There are many and I can't give an exhaustive list... here are some
that I would like to highlight (in no particular order):
Vim's habit of completing the full filename of the first match on :e has always
annoyed me. Rhonda pointed me to wildmode - thanks!
set wildmode=longest,list:longest,list:full
This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (170 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects.
This month passed by very quickly since I attended both the Libre Software Meeting / RMLL and the DebConf.
Libre Software Meeting / RMLL
I attended only 3 days out of the 6 but that was a deliberate choice since I was also attending DebConf for a full week later in the month.
During those 3 days I helped with the Debian booth that was already well taken care of by Fr d ric Perrenot and Arnaud Gambonnet. Unfortunately we did not have any goodies to sell. We (as in Debian France) should do better in this regard next time.
One of the talks I attended presented EnVenteLibre. This website started as an online shop for two French associations (Ubuntu-fr, Framasoft). They externalize all the logistic to a company and only have to care about ordering goodies and delivering to the warehouse of the logistic company. They can also take some goodies from the warehouse and ship them for a conference, etc. We discussed a bit to see how Debian France could join, they are even ready to study what can be done to operate at the international level (that would be interesting for Debian with all the local associations that we have throughout the world).
Back to the LSM, while I had 3 good days in Strasbourg, it seems to mee that the event is slowly fading out it s far from being an international event and the number of talks doesn t make for a better quality.
BTW, do you remember that Debconf 0 and Debconf 1 were associated to this event while it was in Bordeaux?
dpkg-source improvements
During my time in Strasbourg (and in particular the travel to go there and back!) I implemented some changes to 3.0 (quilt) source format. It will now fail to build the source package if there are upstream changes that are not properly recorded in a quilt patch:
dpkg-source: info: local changes detected, the modified files are: 2ping-1.1/README dpkg-source: info: you can integrate the local changes with dpkg-source --commit dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/2ping_1.1-1.diff.cki8YBAs the error message hints, there s a new
--commit command supported by dpkg-source that will generate the required quilt patch to fix this. In the processe you will have to submit a name and edit the patch header (pre-formatted with DEP3 compatible fields). You can get back the old behavior with the --auto-commit option.
Build flags changes
Ever since we adopted the Ubuntu changes to let dpkg-buildpackage set some build related environment variables (see #465282), many Debian people expressed their concerns with this approach both because it broke some packages and because those variables are not set if you execute debian/rules directly.
In the end, the change was not quickly reverted and we fixed the package that this change broke. Despite this we later decided that the correct approach to inject build flags would be a new interface: dpkg-buildflags.
Before changing dpkg-buildpackage to no longer set the compilation flags, I wanted to ensure dpkg-buildflags had some decent coverage in the archive (to avoid breaking too many packages again). My criteria was that CDBS and dh (of debhelper) should be using it. With the recent debhelper change (see #544844) this has been reached so I changed dpkg-buildpackage accordingly.
Makefile snippets provided by dpkg
At the same time, I also wanted an easy way for maintainers not using dh or CDBS to be able to fix their package easily and go back to injecting the compilation flags in the environment but doing it from the rules files. Starting with the next version of dpkg, this will be possible with something like this:
DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/default.mkWithout DPKG_EXPORT_BUILDFLAGS the variables are not exported in the environment and have no effect unless you use them somewhere. More than build flags, this will also provide a bunch of other variables that can be useful in a rules files: all the variables provided by dpkg-architecture, vendor related variables/macro and some basic package information (mainly version related). dpkg-buildflags improvements Given the renewed importance that dpkg-buildflags will take now that dpkg-buildpackage no longer sets the corresponding environment variables, I thought that I could give it some love by fixing all the open issues and implementing some suggestions I got. I also had a chat with a few members of the technical committee to discuss how hardening build flags could be enabled in Debian and this also resulted in a few ideas of improvements. In the end, here are the main changes implemented:
--export=configure command to inject build flags on the ./configure command line (see commit);--dump command that is the default (see #603435).No comment Liked this article? Click here. My blog is Flattr-enabled.
Transitioning Python modules to dh_python2 is
straightforward.
I removed LOADS of magic from python-radix. I especially like the complexity reduction in
debian/rules,
but debian/control also got some fields removed.
Because of some problem with Denic's DNSSEC testbed and bind resolvers,
dlv.isc.org has removed all DLV records for *.de domains. WTF.
29. April 2011
At work, I'm dealing with lots of different database setups, luckily mostly
PostgreSQL running on Debian. At the same time, a fair amount of the tools in
the PostgreSQL ecosystem (not the PostgreSQL server packages itself) are not in
the best shape in the Debian archive.
I'm trying to change that by adopting some of the packages. So far, I have
fixed a few RC bugs where packages where suddenly trying to build against
PostgreSQL 9.0 while expecting 8.4. To my surprise, there are no packages yet
in the archive that support multiple PostgreSQL versions in parallel. There is
even a package ready to help doing this -
postgresql-server-dev-all,
but apparently nobody has used it yet. It turned out that after working around
a few trivial problems and adding just a few lines of sh code, it was pretty
straightforward
to port skytools and
postgresql-pllua
to 9.0 while keeping 8.4 support. The latter has no version-specific code left
in debian/ except for a list of supported versions in debian/pgversions, so a
future port to 9.1 will be trivial. (Fun fact: the old postgresql-pllua version
0.8.1 was actually a typoed 0.3.1 version.)
Most PostgreSQL tools use a common
subversion repository on Alioth,
but there is no common mailing list address that is put into the Uploaders
fields, so it is hard to get an overview over the state of all packages. I've
compiled a list of all packages in svn, git, bzr (the server packages), and a
few others
in DDPO
to fix that for now.
Other packages I've updated so far are
pgtune,
pgbouncer, and
pgpool2.
Using a virtual IP managed by heartbeat is a nice way to work around the slow
fallback behavior with multiple nameservers in /etc/hosts. But unlike ntpd,
bind9 doesn't automatically listen on new IPs on the system.
Here's a cute hack to fix that:
# cat /etc/ha.d/haresources
server01 bind9release IPaddr::10.0.0.3 bind9takeover
# cat /etc/ha.d/resource.d/bind9release
#!/bin/sh
# when giving up resources, reload bind9
case $1 in
stop) /etc/init.d/bind9 reload ;;
esac
exit 0
# cat /etc/ha.d/resource.d/bind9takeover
#!/bin/sh
# on takeover, reload bind9
case $1 in
start) /etc/init.d/bind9 reload ;;
esac
exit 0
When my wife bought her HP 2605dn color laser, she had also ordered a set of
replacement cartridges because the originals would supposedly not last very
long. It turned out that they would last over two years, though.
Now, the black cartridge was empty. The replacements are original HP
components, but recycled/refilled second hand from a different source. I put in
the black one, and the trouble started with the new drum having a big scratch
that would appear in every print. After two years, returning the cartridge was
not an option. As the old drum was still good, the idea was
to put the new toner into the old cartridge. A bit of googling (and visual
inspection) quickly revealed that you are not supposed to do this, the device
doesn't have any facilities to access anything.
Some post did indicate though that the cartridge actually consists of two parts
that are only held together by two pivot pins and two small springs. If you
pull the two parts apart a bit, you can feel the axis the parts are moving
around. So, I would try to use the old drum part with the new toner container
part.
Removing the springs is easy (also removing the flap covering the drum, along
with a tiny third spring). The two pivot pins are pretty inaccessible, but I
managed to pull out both using a pointy tong. One pin is made of metal, if you
need more space you can drill a small hole right next to it. The other pin is
made of plastic with a small hole in it, in one case I succeeded by screwing in
a little screw and pulling at it.
Reassembling the parts is not so hard. I put the "new" cartridge into the
printer, waited for the initialization to finish, only to find out the printer
would still think the cartridge was empty and should be replaced. Duh.
I then discovered a small chip attached to one corner of the drum unit,
probably carrying product ID and some serial number. Luckily, it was easy to
be removed and exchanged with the other drum unit. Still, the printer thought
the cartridge was empty. Some (windows) driver re-installations later it was
clear that there is no "ignore fill level and print anyway" option. (Cups
didn't print either.)
The HP Support Forum has a long
Ink cartridge empty but it's not
thread with lots of complaints but few answers. (Their problem is mostly with
new HP cartridges becoming "empty" after a few days.) Someone suggests trying
to cold reset the printer. For the 2605dn, that's holding the left and right
buttons while powering on. I removed the cartridges for doing so. When I had
put them back in, the printer asked me to confirm that non-HP material was
installed, and subsequently didn't display any fill level for the black
cartridge anymore, just " ? " in the display.
Printing works now. Yay.
(Lesson learned: I still hate dealing with printers.)
Jan 5 2011, 3070g, 54cm
Julia, Mom and Dad are all well and very happy.
Mutt's configuration is sometime more a toolbox than something offering ready
solutions, and "how to I use multiple accounts?" is one of the most FAQs.
Here's a condensed version of my setup.
In the most simple solution, just 'c'hange folders to the IMAP server:
c imaps://imap.example.com <enter>
c imaps://imap.otherdomain.tld <enter>
# .mutt/muttrc
macro index <f2> '<change-folder>imaps://imap.example.com<enter>'
macro index <f3> '<change-folder>imaps://imap.otherdomain.tld<enter>'
# .mutt/account.example
set from=me@example.com
set hostname="example.com"
set folder="imaps://imap.example.com/"
set postponed="=Drafts"
set spoolfile="imaps://imap.example.com/INBOX"
set signature="~/.mutt/signature.example"
# .mutt/account.otherdomain
set from=myself@otherdomain.tld
set hostname="otherdomain.tld"
set folder="imaps://imap.otherdomain.tld/"
set postponed="=Drafts"
set spoolfile="imaps://imap.otherdomain.tld/INBOX"
set signature="~/.mutt/signature.otherdomain"
# .mutt/muttrc
folder-hook 'example.com' 'source ~/.mutt/account.example'
folder-hook 'otherdomain.tld' 'source ~/.mutt/account.otherdomain'
# switch to default account on startup
source ~/.mutt/account.example
macro index <f2> '<sync-mailbox><enter-command>source ~/.mutt/account.example<enter><change-folder>!<enter>'
macro index <f3> '<sync-mailbox><enter-command>source ~/.mutt/account.otherdomain<enter><change-folder>!<enter>'
account-hook example.org 'set imap_user=me imap_pass=pw1'
account-hook otherdomain.tld 'set imap_user=myself imap_pass=pw2'
set my_pw_example= gnome-keyring-query get mutt_example
set my_pw_otherdomain= gnome-keyring-query get mutt_otherdomain
account-hook example.org 'set imap_user=me imap_pass=$my_pw_example'
account-hook otherdomain.tld 'set imap_user=myself imap_pass=$my_pw_otherdomain'
$ lftp -c 'mget http://backports.debian.org/debian-backports/pool/main/p/postgresql-8.4/*_8.4.5-1~bpo50+1_amd64.deb'
$ lftp -c 'mget http://backports.debian.org/debian-backports/pool/main/p/postgresql-8.4/*_8.4.5-1~bpo50+1_amd64.deb'
Next.